home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20010306-20010921
/
000000_news@columbia.edu _Tue Mar 6 14:21:06 2001.msg
next >
Wrap
Internet Message Format
|
2001-09-20
|
4KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by monire.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA15496
for <kermit.misc@cpunix.cc.columbia.edu>; Tue, 6 Mar 2001 14:21:06 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id OAA12827
for kermit.misc@watsun.cc.columbia.edu; Tue, 6 Mar 2001 14:20:03 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: fdc@columbia.edu (Frank da Cruz)
Subject: New defaults for new Kermit releases
Date: 6 Mar 2001 19:20:01 GMT
Organization: Columbia University
Message-ID: <983d91$cgk$1@newsmaster.cc.columbia.edu>
To: kermit.misc@columbia.edu
In preparing the forthcoming new Kermit releases, it occurred to me that
we have an opportunity to modernize Kermit's treatment of serial ports,
which is still based on 1980s assumptions:
. Serial ports are mostly used for direct connections
. Modems have all different kinds of command sets
Because of these assumptions, it has always been necessary to SET MODEM
TYPE first, before opening the serial port with SET LINE, so the
device-opening code invoked by SET LINE knows to set the right
operating-system-specific magic bits that say "this device will be used
for dialing, so don't require Carrier until later".
But this confuses many people, who don't understand why the order of
SET MODEM TYPE and SET LINE should matter -- especially since it doesn't
matter on *some* operating systems.
These days I think it is safe to say that:
. Serial ports are mostly used with modems
. Almost every modem supports the basic AT command set
Therefore we should be able to change Kermit's default modem type from
NONE to some generic kind of AT-command-set modem. If we did, then
would work:
set line /dev/blah
set modem type usrobotics
set speed 57600
dial 7654321
And this would continue to work:
set modem type usrobotics
set line /dev/blah
set speed 57600
dial 7654321
And this would work in most cases:
set line /dev/blah
set speed 57600
dial 7654321
And for a direct connection:
set line /dev/blah
set speed 57600
connect
should work as before. If there is no carrier, Kermit would complain and
CONNECT would fail (unless CARRIER-WATCH was OFF). If there is Carrier,
Kermit would CONNECT normally. If there was a problem, you could SET
MODEM TYPE DIRECT to get around it.
So far so good? Then the question is, what should the generic modem type
be? We already have a GENERIC-HIGH-SPEED modem type that comes very close
to fitting the bill: it uses AT commands for dialing and hanging up, etc,
the basic set that is common to all modems that use AT commands. It does
NOT send any commands to configure the modem's options (like flow control,
data compression, etc), since these are not portable among different
brands of modems.
The only trouble with with GENERIC-HIGH-SPEED is that it uses AT&F to
initialize the modem, which doesn't work with all modems -- for example
it does not work with US Robotics. Maybe we could use ATZ instead, but
we have had bad experiences with it in the past (it makes some modems
reboot themselves; all their signals go off and on, which tends to cause
trouble with the computer's device driver).
So perhaps the best course is to (a) change GENERIC-HIGH-SPEED not to send
AT&F at all and simply assume the modem is configured appropriately (as
most are), and (b) make GENERIC-HIGH-SPEED the default modem type, rather
than NONE.
Unless anybody sees a fatal flaw in this reasoning, we'll try this in the
next C-Kermit 7.1 Alpha test.
While I have your attention, I should mention that I'm also planning to
change the default TERMINAL BYTESIZE from 7 to 8. It has been 7 forever,
based on the 1980s-era assumption that the host is likely to be using
parity, but this is now almost vanishingly unlikely. Does anybody
disagree?
- Frank